This depends upon changes in #3944 and will be rebased once that merges to main.

I wonder if it'd make sense to support the WASM case in lib/prism/ffi.rb directly and e.g. define LibRubyParser as WASM::PRISM or so in that case, or to share some of the logic.
This looks like an early prototype as much of the logic is copied and probably not working yet (since it refers LibRubyParser and that's not set in the new file).

This looks like an early prototype

Yes, that's why it's a draft.

Most recent commit is an attempt to move the PRISM_SERIALIZE_ONLY_SEMANTIC_FIELDS into a macro. I'll explain why.

The JVM WASM builds need to take two forms:

• A semantic-only version for the WASM build for JRuby's internal parser, which uses the Loader API.
• A non-semantic version for the WASM build for the JRuby gem, which uses the same logic as FFI.

These two artifacts should be sibling modules under java/ and built together as part of the Maven build lifecycle. Ideally there would remain three steps to build this:

• Generate the templated sources
• Build the two WASM files
• Build the Maven artifacts

But because the templated sources must be generated twice, once for semantic-only and again for non-semantic, the build process ends up being much more complicated:

• Generate the semantic-only sources
• Build the semantic-only WASM
• Generate the non-semantic sources
• Build the non-semantic WASM
• Build the Maven artifacts

By moving the semantic-only flag into a C macro, a single set of sources can be generated and customized at C compile time, allowing a single make target to build both WASM forms.

Ideally the other two major C templating flags could also move into build-time macros:

• Pretty printing could be omitted at C compile time and eliminated from the resulting binary.
• Node ID could be omitted for builds that do not want it. (I had to tweak the INCLUDE_NODE_ID template flag because it was intertwined with the templated PRISM_SERIALIZE_ONLY_SEMANTICS_FIELDS

Really, the only tricky part is for the Java API that has two forms: with node ID and without node ID, and I think we can handle that a different way (perhaps by adding another flag to the serialization header?)